Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keyword display improvements #16669

Merged
merged 4 commits into from
Jun 28, 2016
Merged

Keyword display improvements #16669

merged 4 commits into from
Jun 28, 2016

Conversation

dhoegh
Copy link
Contributor

@dhoegh dhoegh commented May 30, 2016

This PR implements several improvement to how keywords is presented to the user. The additions in each commit is listed bellow

    1. adds display of variable keyword arguments such as kwargs.... This change causes the vararg keywords to be displayed in method list and other places.
    1. adds the display of keywords to method completion
julia> split(<tab>
split{T<:SubString{T<:AbstractString}}(str::T, splitter; limit, keep) at strings/util.jl:126
split(str::AbstractString) at strings/util.jl:151
split{T<:AbstractString}(str::T, splitter; limit, keep) at strings/util.jl:127

Example from #15639:

type FooCon
    x
end
type BarCon
    x
end
function addConstraint(c::FooCon)
    println("addCon(FooCon)")
end
function addConstraint(c::BarCon; uncset=nothing)
    println("addCon(BarCon,$uncset)")
    # Oh, BarCon was suppossed to be a FooCon, let me erroneously pass
    # on this kwarg which isn't supported
    addConstraint(FooCon(c.x), uncset=uncset)
end
julia> addConstraint(BarCon(1))
addCon(BarCon,nothing)
ERROR: MethodError: no method matching addConstraint(::FooCon; uncset=nothing)
Closest candidates are:
  addConstraint(::FooCon) got an unrecognized keyword argument "uncset"
  addConstraint(::BarCon; uncset)
 in #addConstraint#1(::Void, ::Function, ::BarCon) at ./REPL[4]:5
 in addConstraint(::BarCon) at ./REPL[4]:2
 in eval(::Module, ::Any) at ./boot.jl:225
 in macro expansion at ./REPL.jl:92 [inlined]
 in (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:46

Note to reviewer please check if the changes in src/julia-syntax.scm is correct as this is my first encounter with lisp.

@IainNZ
Copy link
Member

IainNZ commented May 30, 2016

@dhoegh can you post the new error message for that case?

@quinnj
Copy link
Member

quinnj commented May 30, 2016

A big +1 to progress with this. In the method lists, I wonder if we should display the default kwarg value too? Seems like that's usually the next question once I know there is a keyword argument involved.

Also probably want to track the updates in #16580 with how keyword arguments will be handled internally.

@dhoegh
Copy link
Contributor Author

dhoegh commented May 30, 2016

I have updated the example.

@@ -123,6 +123,16 @@ function showerror(io::IO, ex::MethodError)
ft = typeof(f)
name = ft.name.mt.name
f_is_function = false
kwargs = Dict{Any,Any}()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think you meant Array{Any}(0) here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, thank you. I have corrected it.

@dhoegh
Copy link
Contributor Author

dhoegh commented May 31, 2016

I have fixed the comment from vtnash. I have taken a brief look at #16580 and the approach used here seems to be adaptable for the PR. Is #16580 slated 0.5 material, because I do think it would be good to get this in 0.5.

@dhoegh dhoegh force-pushed the kword branch 2 times, most recently from 1091f8a to e808e07 Compare May 31, 2016 19:22
@nalimilan
Copy link
Member

Great!

Though for consistency with positional arguments, the value of keyword arguments shouldn't be printed on MethodError. So this:

ERROR: MethodError: no method matching addConstraint(::FooCon; uncset=nothing)

would rather be:

ERROR: MethodError: no method matching addConstraint(::FooCon; uncset::Void)

Also, maybe "unsupported" would be better than "unrecognized".

@IainNZ
Copy link
Member

IainNZ commented May 31, 2016

@nalimilan why would it be Void? Surely its Any?

@nalimilan
Copy link
Member

@IainNZ AFAIK the displayed type is that of the passed argument, not the one in the signature (indeed, that argument doesn't even exist for that method, so it doesn't have a type).

@IainNZ
Copy link
Member

IainNZ commented May 31, 2016

That... doesn't make any sense then, right? Doesn't seem like something to perpetuate

@@ -150,6 +160,13 @@ function showerror(io::IO, ex::MethodError)
print(io, "::$typ")
i == length(arg_types_param) || print(io, ", ")
end
if 0 < length(kwargs)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use isempty instead of comparing length to 0

@dhoegh dhoegh force-pushed the kword branch 3 times, most recently from 069b03c to 673826b Compare June 5, 2016 12:09
@dhoegh
Copy link
Contributor Author

dhoegh commented Jun 5, 2016

I have addressed the comment from tkelman and changed "unrecognized" to "unsupported" based on nalimilan comment.

Regarding display of default values, that seem to require more than a trivial amount of look through the AST of the kwsorter function. Therefore I do not think it is appropriate to implement it here, but it would be a nice addition.

@dhoegh
Copy link
Contributor Author

dhoegh commented Jun 13, 2016

Bump, any further comments or thoughts.

if !isempty(kwargs)
print(io, "; ")
for (i ,(k, v)) in enumerate(kwargs)
print(io, k, "=", v)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use show(IOContext(io, :limit => true), v), not print(io, v) for v

(also the \space, are in the wrong order on the previous line)

@vtjnash
Copy link
Member

vtjnash commented Jun 23, 2016

sorry this took so long to review. I've been coming back to this every few days trying to make sure I was understanding how everything would interact.

Can I ask you to add a test for the behavior with multiple kwargs (multiple matching, multiple not matching)?

@StefanKarpinski
Copy link
Member

Given that this is a display change, which tends to be less likely to break people's code, can't we merge this and then patch it up?

@dhoegh dhoegh force-pushed the kword branch 2 times, most recently from c353489 to f49fcb9 Compare June 26, 2016 08:56
…method in show_method_candidates with a text stating the not matching keyword. Fix JuliaLang#15639
@dhoegh
Copy link
Contributor Author

dhoegh commented Jun 26, 2016

I have fixed the trivial comments and added test for multiple kwargs matching and multiple not matching at line https://github.com/dhoegh/julia/blob/d4e8792075735c9a71e52f3ddad62cb96bf589ad/test/replutil.jl#L112-L115. I have squashed the commit where the review comments was addressed away. My time is very limited right now, so my response time the next couple of weeks could be long.

@vtjnash
Copy link
Member

vtjnash commented Jun 28, 2016

Thanks. This is great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MethodError message misleading/wrong on 0.4, very hard to read on 0.5
7 participants